The use of Digital Certificates must be implemented in accordance with security requirements.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-3225	ITNT0040	SV-7143r3_rule	DCCS-1 DCCS-2 ECCD-1 ECCD-2	Medium

Description
Digital certificates are a primary requirement for Secure Sockets Layer (i.e., SSL). The origin of a certificate, the Certificate Authority (i.e., CA), is crucial in determining if the certificate should be trusted. Failure to maintain a list of appropriate host-based CA certificates could result in unauthorized access to the host. Certificate name filtering is a facility that allows multiple certificates to be mapped to a single ACP userid. Rather than matching a certificate stored in the ACP to determine the userid, criteria rules are used. Depending on the filter criteria, a large number of client certificates could be mapped to a single userid. Failure to properly control the use of certificate name filtering could result in the loss of individual identity and accountability.

Description

Digital certificates are a primary requirement for Secure Sockets Layer (i.e., SSL). The origin of a certificate, the Certificate Authority (i.e., CA), is crucial in determining if the certificate should be trusted. Failure to maintain a list of appropriate host-based CA certificates could result in unauthorized access to the host. Certificate name filtering is a facility that allows multiple certificates to be mapped to a single ACP userid. Rather than matching a certificate stored in the ACP to determine the userid, criteria rules are used. Depending on the filter criteria, a large number of client certificates could be mapped to a single userid. Failure to properly control the use of certificate name filtering could result in the loss of individual identity and accountability.

STIG	Date
z/OS RACF STIG	2016-01-04

Details

Check Text ( C-35843r2_chk )
NOTE: The procedures in this checklist item presume the domain being reviewed is using RACF as the certificate store. Self-Signed Certificates If the domain being review is not a production system and is only used for test and development, this Self-Signed Certificates review can be skipped. a) From PDI Screen Sort Order ITCP0060, use the userid(s) assigned to the TCP/IP address space(s) and issue the following RACF command to list the certificate(s) associated with the TCPIP userid(s): RACDCERT ID(tcpip userid) LIST b) If no certificate information is found, there is NO FINDING. NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks. c) If the digital certificate information indicates that the issuer’s distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). Examples of an acceptable DoD CA are: DoD PKI Class 3 Root CA DoD PKI Med Root CA d) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING. An example of a self-signed certificate would be site information displayed as the issuer’s distinguished name. e) Using the userid(s) assigned to the TCP/IP address space(s), issue the following RACF command to list any associated key rings: RACDCERT ID(tcpip userid) LISTRING() For each Certificate Owner, issue the following RACF command to list the certificate(s) associated with their userid: RACDCERT ID(cert owner userid) LIST f) If the digital certificate information indicates that the issuer’s distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). g) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING. DoD PKI Root Certificate Authority If the domain being review is not a production system and is only used for test and development, this DoD PKI Root Certificate Authority review can be skipped. h) Issue the following RACF command to list the Certificate Authorities: RACDCERT CERTAUTH LIST i) If no certificate information is found, there is NO FINDING. NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks. j) If the digital certificate information indicates that all certificates lead to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). Examples of an acceptable DoD CA are: DoD PKI Class 3 Root CA DoD PKI Med Root CA k) Other than the exception noted below, if the digital certificate information indicates that any certificate is from a non-DoD entity (e.g., Verisign, Thawte, IBM World Registry) and the Status is TRUST, this is a FINDING. Exception: For a site running IBM WebSphere there is a certificate with the label "WebSphereCA" that is permitted. Certificate Name Filtering Currently the RACDCERT command does not support a generic userid value of ID() LISTMAP to list all the certificate name filters defined to RACF. However, the following commands can be issued to determine if certificate name filtering may be implemented. l) If certificate name filtering is in use, collect documentation describing each active filter rule and written approval from the IAM to use the rule. m) Issue the SETROPTS LIST command. If the DIGTNMAP resource class is active, RACF is ready to process any certificate name filters with a Status of TRUST. The DIGTNMAP resource class should not be active unless certificate name filtering is desired. If the DIGTNMAP resource class is not active, there is NO FINDING. n) Certificate name filters are stored as profiles in the DIGTNMAP resource class. The RLIST command is not intended for use with profiles in the DIGTNMAP resource class. However it can be used to determine if any profiles are defined. (NOTE: The information will not be displayed in a suitable format to easily interpret the filter.) RLIST DIGTNMAP * If there is nothing to list in the DIGTNMAP resource class, there is NO FINDING. If profile information is displayed, one or more certificate name filters are defined to RACF. Under the NAME heading of each profile listing is the userid the filter is being mapped to. Issue the following command the list the certificate name filter associated with each userid: RACDCERT ID(profile name userid) LISTMAP NOTE: Certificate name filters are only valid when their Status is TRUST. Therefore, you may ignore filters with the NOTRUST status. o) If the DIGTNMAP resource class is active and certificate name filters have a Status of TRUST, certificate name filtering is in use. p) If certificate name filtering is in use and filtering rules have been documented and approved by the IAM, there is NO FINDING. q) If certificate name filtering is in use and filtering rules have not been documented and approved by the IAM, this is a FINDING.

Check Text ( C-35843r2_chk )

NOTE: The procedures in this checklist item presume the domain being reviewed is using RACF as the certificate store.

Self-Signed Certificates

If the domain being review is not a production system and is only used for test and development, this Self-Signed Certificates review can be skipped.

a) From PDI Screen Sort Order ITCP0060, use the userid(s) assigned to the TCP/IP address space(s) and issue the following RACF command to list the certificate(s) associated with the TCPIP userid(s):

RACDCERT ID(tcpip userid) LIST

b) If no certificate information is found, there is NO FINDING.

NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks.

c) If the digital certificate information indicates that the issuer’s distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Examples of an acceptable DoD CA are:
DoD PKI Class 3 Root CA
DoD PKI Med Root CA

d) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING.

An example of a self-signed certificate would be site information displayed as the issuer’s distinguished name.

e) Using the userid(s) assigned to the TCP/IP address space(s), issue the following RACF command to list any associated key rings:

RACDCERT ID(tcpip userid) LISTRING(*)

For each Certificate Owner, issue the following RACF command to list the certificate(s) associated with their userid:

RACDCERT ID(cert owner userid) LIST

f) If the digital certificate information indicates that the issuer’s distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

g) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING.

DoD PKI Root Certificate Authority

If the domain being review is not a production system and is only used for test and development, this DoD PKI Root Certificate Authority review can be skipped.

h) Issue the following RACF command to list the Certificate Authorities:

RACDCERT CERTAUTH LIST

i) If no certificate information is found, there is NO FINDING.

NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks.

j) If the digital certificate information indicates that all certificates lead to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Examples of an acceptable DoD CA are:
DoD PKI Class 3 Root CA
DoD PKI Med Root CA

k) Other than the exception noted below, if the digital certificate information indicates that any certificate is from a non-DoD entity (e.g., Verisign, Thawte, IBM World Registry) and the Status is TRUST, this is a FINDING.

Exception: For a site running IBM WebSphere there is a certificate with the label "WebSphereCA" that is permitted.

Certificate Name Filtering

Currently the RACDCERT command does not support a generic userid value of ID(*) LISTMAP to list all the certificate name filters defined to RACF. However, the following commands can be issued to determine if certificate name filtering may be implemented.

l) If certificate name filtering is in use, collect documentation describing each active filter rule and written approval from the IAM to use the rule.

m) Issue the SETROPTS LIST command. If the DIGTNMAP resource class is active, RACF is ready to process any certificate name filters with a Status of TRUST. The DIGTNMAP resource class should not be active unless certificate name filtering is desired.

If the DIGTNMAP resource class is not active, there is NO FINDING.

n) Certificate name filters are stored as profiles in the DIGTNMAP resource class. The RLIST command is not intended for use with profiles in the DIGTNMAP resource class. However it can be used to determine if any profiles are defined. (NOTE: The information will not be displayed in a suitable format to easily interpret the filter.)

RLIST DIGTNMAP *

If there is nothing to list in the DIGTNMAP resource class, there is NO FINDING.

If profile information is displayed, one or more certificate name filters are defined to RACF. Under the NAME heading of each profile listing is the userid the filter is being mapped to. Issue the following command the list the certificate name filter associated with each userid:

RACDCERT ID(profile name userid) LISTMAP

NOTE: Certificate name filters are only valid when their Status is TRUST. Therefore, you may ignore filters with the NOTRUST status.

o) If the DIGTNMAP resource class is active and certificate name filters have a Status of TRUST, certificate name filtering is in use.

p) If certificate name filtering is in use and filtering rules have been documented and approved by the IAM, there is NO FINDING.

q) If certificate name filtering is in use and filtering rules have not been documented and approved by the IAM, this is a FINDING.

Fix Text (F-31096r2_fix)
Certificate Management Digital certificates are a primary requirement for SSL processing. In this section the following considerations in managing certificates are discussed: - Location – There are multiple options for storing certificates. - Origin – The origin of a certificate, the Certificate Authority, is crucial in determining if the certificate should be trusted. - Name filtering – Multiple certificates can be mapped to a single ID. - On z/OS systems, an MVS data set, an HFS file, or the resident ACP can be the storage location for digital certificates. When they are stored by the ACP, commands specific to the ACP are used. Digital certificates should be stored according to the following guidelines: - On z/OS systems, the ACP should be used as the location for certificates. Configuration Statements. - Each digital certificate includes Certificate Authority (CA) information as the logical origin of the certificate. The presence of the CA’s information indicates, to some level of trust, that the owner of the certificate is recognized by that CA to be who they claim to be. Each host maintains a list of CAs that are considered trusted. When client authentication is utilized, the CA from the client’s certificate is compared to the host’s list. If there is a match, a major criterion of SSL authentication is satisfied. Therefore, the list of CAs maintained on the host has a crucial impact on authentication decisions. - Software is available on most host platforms, including z/OS, which allows a host to act as a Certificate Authority. When certificates are created on that host for use on that host, the certificates are considered to be self-signed. Certificates that are self-signed are generally considered to be of limited security value because no independent oversight of user identification is maintained. Review the list of host-based CAs and ensure they are limited to those with a trust hierarchy that leads to a DOD PKI Root CA or EXTERNAL CERTIFICATION AUTHORITY(ECA). Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). Ensure any certificate name filtering rules in use are documented and approved by the IAM. 1. Consult the RACF documentation, specifically the SAG regarding usage of the RACF commands to administer PKI Certificates. 2. For information on obtaining an SSL certificate in the DISA CSD environment, send email inquiry to disaraoperations@disa.mil for more info.

Fix Text (F-31096r2_fix)

Certificate Management

Digital certificates are a primary requirement for SSL processing. In this section the following considerations in managing certificates are discussed:
- Location – There are multiple options for storing certificates.
- Origin – The origin of a certificate, the Certificate Authority, is crucial in determining if the certificate should be trusted.
- Name filtering – Multiple certificates can be mapped to a single ID.
- On z/OS systems, an MVS data set, an HFS file, or the resident ACP can be the storage location for digital certificates. When they are stored by the ACP,
commands specific to the ACP are used.

Digital certificates should be stored according to the following guidelines:
- On z/OS systems, the ACP should be used as the location for certificates.

Configuration Statements.
- Each digital certificate includes Certificate Authority (CA) information as the logical origin of the certificate. The presence of the CA’s information indicates, to some level of
trust, that the owner of the certificate is recognized by that CA to be who they claim to be. Each host maintains a list of CAs that are considered trusted. When client authentication is utilized, the CA from the client’s certificate is compared to the host’s list. If there is a match, a major criterion of SSL authentication is satisfied. Therefore, the list of CAs maintained on the host has a crucial impact on authentication decisions.
- Software is available on most host platforms, including z/OS, which allows a host to act as a Certificate Authority. When certificates are created on that host for use on that
host, the certificates are considered to be self-signed. Certificates that are self-signed are generally considered to be of limited security value because no independent oversight of user identification is maintained.

Review the list of host-based CAs and ensure they are limited to those with a trust hierarchy that leads to a DOD PKI Root CA or EXTERNAL CERTIFICATION AUTHORITY(ECA). Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Ensure any certificate name filtering rules in use are documented and approved by the IAM.

1. Consult the RACF documentation, specifically the SAG regarding usage of the RACF commands to administer PKI Certificates.

2. For information on obtaining an SSL certificate in the DISA CSD environment, send email inquiry to disaraoperations@disa.mil for more info.